剛踏入 RPA 的世界時，官方教學影片總是看起來無比美好：拖拉一個「Click」活動、滑鼠移到網頁按鈕上一點，機器人就會乖乖聽話執行。
然而，當興致勃勃拿企業內部的表單系統實測，準備寫個自動化點擊時，通常不到五分鐘就會迎來當頭棒喝——明明昨天錄製時還跑得順順的流程，今天一按「Run」，機器人就卡在那邊苦苦等待 30 秒，最後無情地噴出紅字：ElementNotFoundException。
今天就來聊聊這個讓所有新手的我遭遇的第一座大山：Selector（選取器）。
一、看似完美的 Click 活動
以內部表單清單為例，想要機器人自動點擊待辦清單裡的第一筆表單：
拖入 Click 活動。
點擊 Indicate in Chrome。
滑鼠對準第一筆表單的編號點下去，出現綠色勾勾，搞定！
但仔細一看活動標題，UiPath 默默生成了這行字： Click '102115090158'
這正是地雷引爆的瞬間。
二、什麼是 Selector？它怎麼看世界？
機器人不像人類，它沒有「眼睛」，它認識網頁元件完全依賴 HTML DOM 樹狀結構的屬性標籤，這段定位字串就稱為 Selector。
當點選了畫面上的表單編號時，UiPath 背後抓取到的 Strict Selector 可能長成這樣：
<html app='chrome.exe' title='電子表單系統' /> <webctrl tag='A' aaname='102115090158' parentid='grid_form' />
aaname='102115090158'：UiPath 為了確保精準，把「當下畫面上看到的單號文字」當成了身分證字號。
致命傷：這個單號是「動態生成」的。明天這張單被審核掉了、或是來了新表單，單號變成了 102115090159，機器人卻依然拿著舊號碼 102115090158 在網頁上滿世界找，自然直接罷工。
三、我嘗試把「寫死」的選取器變動態
遇到這種動態內容，顯然不能只依賴錄製器的預設行為，必須人工介入調整 Selector。
首先嘗試
解法 1：從「認號碼」改成「認位置」（點擊第一列）
如果自動化流程的目標永遠是「處理清單中最上方的那筆表單」，直覺上就不該依賴具體的單號文字，而是告訴機器人：「請點擊表格第一列的連結」。
操作步驟看似很直觀：
開啟該 Click 活動的 Target 編輯器（或開啟 UI Explorer 檢視 DOM 樹）。
取消勾選 綁死當前單號的屬性（例如 aaname、innertext）。
企圖讓機器人只靠標籤與父層容器去定位如範圍圖示去比對
本以為拿掉單號就大功告成，按下驗證（Validate）準備收工，結果編輯器直接亮起黃燈，跳出無情的警告：
「Multiple matches found」。
沒錯，剛搬開「動態單號」這顆大石頭，眼前立刻又砸下一座大山——多重目標（Ambiguous Selector）。
把單號拿掉後，這段 Selector 的意思變成了：「請幫我點擊在 grid_form 底下、任何標籤為 的連結」。
偏偏整張待辦清單裡有十幾筆表單，每一列都有一個 。對機器人來說，就像你走進會議室喊「那位穿襯衫的同事請起立」，全場一半的人都站起來，機器人當場當機：你到底要我點哪一個？
下班時間已到，今天能確認問題核心是「定位維度不足」，也算跨出了一大步。
至於要如何教會機器人看懂「第一列」、精準在茫茫人海中只鎖定第一個目標，並且安全避開多重匹配的雷區？
今天先到這裡，明天我們繼續來拆解這個「多重目標」的定位謎題！
iThome鐵人賽
看影片追技術